Control plane protection is not enabled.

Overview

Finding ID	Version	Rule ID	IA Controls	Severity
V-19188	NET0966	SV-21168r2_rule		Medium

Description
The Route Processor (RP) is critical to all network operations as it is the component used to build all forwarding paths for the data plane via control plane processes. It is also instrumental with ongoing network management functions that keep the routers and links available for providing network services. Hence, any disruption to the RP or the control and management planes can result in mission critical network outages. In addition to control plane and management plane traffic that is in the router’s receive path, the RP must also handle other traffic that must be punted to the RP—that is, the traffic must be fast or process switched. This is the result of packets that must be fragmented, require an ICMP response (TTL expiration, unreachable, etc.) have IP options, etc. A DoS attack targeting the RP can be perpetrated either inadvertently or maliciously involving high rates of punted traffic resulting in excessive RP CPU and memory utilization. To maintain network stability, the router must be able to securely handle specific control plane and management plane traffic that is destined to it, as well as other punted traffic. Using the ingress filter on forwarding interfaces is a method that has been used in the past to filter both forwarding path and receiving path traffic. However, this method does not scale well as the number of interfaces grows and the size of the ingress filters grow. Control plane policing can be used to increase security of routers and multilayer switches by protecting the RP from unnecessary or malicious traffic. Filtering and rate limiting the traffic flow of control plane packets can be implemented to protect routers against reconnaissance and DoS attacks allowing the control plane to maintain packet forwarding and protocol states despite an attack or heavy load on the router or multilayer switch.

Description

The Route Processor (RP) is critical to all network operations as it is the component used to build all forwarding paths for the data plane via control plane processes. It is also instrumental with ongoing network management functions that keep the routers and links available for providing network services. Hence, any disruption to the RP or the control and management planes can result in mission critical network outages. In addition to control plane and management plane traffic that is in the router’s receive path, the RP must also handle other traffic that must be punted to the RP—that is, the traffic must be fast or process switched. This is the result of packets that must be fragmented, require an ICMP response (TTL expiration, unreachable, etc.) have IP options, etc. A DoS attack targeting the RP can be perpetrated either inadvertently or maliciously involving high rates of punted traffic resulting in excessive RP CPU and memory utilization. To maintain network stability, the router must be able to securely handle specific control plane and management plane traffic that is destined to it, as well as other punted traffic. Using the ingress filter on forwarding interfaces is a method that has been used in the past to filter both forwarding path and receiving path traffic. However, this method does not scale well as the number of interfaces grows and the size of the ingress filters grow. Control plane policing can be used to increase security of routers and multilayer switches by protecting the RP from unnecessary or malicious traffic. Filtering and rate limiting the traffic flow of control plane packets can be implemented to protect routers against reconnaissance and DoS attacks allowing the control plane to maintain packet forwarding and protocol states despite an attack or heavy load on the router or multilayer switch.

STIG	Date
Perimeter Router Security Technical Implementation Guide Juniper	2017-12-07

Details

Check Text ( C-23286r3_chk )
There are numerous rate limiters built into both the Packet Forwarding Engine and the RE to manage exception traffic to and from the RE. Traffic destined to the system is prioritized upon receipt based on protocol in the PFE (forwarding plane). Legitimate traffic bound for the RE is throttled and queued based on protocol priority and appropriately scheduled for transmission across the PFE to RE interface. Juniper is unique. For the most part, ICMP processing is processed by the PFE. This is especially helpful for packets with a next-hop of discard. The forwarding board generates the ICMP unreachable, not the routing engine. These mechanisms aren't configurable and have always been part of the Juniper M/T series architecture. In addition, Juniper handles fragmentation in the data plane, not the RE. Step 1: Verify that an inbound filter has been applied to the loopback interface to restrict traffic destined to the router. The interface configuration should look similar to the following: interfaces { lo0 { unit 0 { family inet { no-redirects; filter { input router-protect-filter; } address 10.10.2.1/32 } } } } Step 2: Verify the filter bound to the router’s loopback address restricts all control plane and management plane traffic. The filter configuration should look similar to the following: firewall { filter router-protect-filter { /* police management and ICMP traffic / policer mgmt-128k { if-exceeding { bandwidth-limit 128k; burst-size-limit 2k; } then discard; } policer mgmt-64k { if-exceeding { bandwidth-limit 64k; burst-size-limit 1k; } then discard; } policer icmp-64k { if-exceeding { bandwidth-limit 64k; burst-size-limit 1k; } then discard; } / drop framgmented ICMP messages / term fragmented-icmp { from { protocol icmp; is-fragment; } then { syslog; discard; } } / allow specific management plane traffic / term ssh-access { from { source-address { 192.168.1.0/24; } protocol tcp; destination-port ssh; } then { policer mgmt-64k; accept; } } term snmp-access { from { source-address { 192.168.1.22/32; 192.168.1.24/32; } protocol udp; destination-port snmp; } then { policer mgmt-128k; accept; } } term tacacs-access { from { source-address { 192.168.1.101/32; } protocol tcp; port tacacs-ds; } then { policer mgmt-64k; accept; } } term ntp-access { from { source-address { 192.168.1.70/32; 192.168.1.77/32; } protocol udp; port ntp; } then { policer mgmt-64k; accept; } } term allow-ICMP { from { source-address { 192.168.1.0/24; } protocol icmp; } then { policer icmp-64k; accept; } } / allow specific control plane traffic */ term guard-bgp { from { source-address { 199.21.32.11/32; 199.21.32.12/32; } protocol tcp; port bgp; } then { syslog; accept; } } term guard-ospf { from { source-address { 199.21.32.11/32; 199.21.32.12/32; } protocol ospf; } then { syslog; accept; } } … … … term default-action { then { syslog; discard; } } } }

Check Text ( C-23286r3_chk )

There are numerous rate limiters built into both the Packet Forwarding Engine and the RE to manage exception traffic to and from the RE. Traffic destined to the system is prioritized upon receipt based on protocol in the PFE (forwarding plane). Legitimate traffic bound for the RE is throttled and queued based on protocol priority and appropriately scheduled for transmission across the PFE to RE interface. Juniper is unique. For the most part, ICMP processing is processed by the PFE. This is especially helpful for packets with a next-hop of discard. The forwarding board generates the ICMP unreachable, not the routing engine. These mechanisms aren't configurable and have always been part of the Juniper M/T series architecture. In addition, Juniper handles fragmentation in the data plane, not the RE.

Step 1: Verify that an inbound filter has been applied to the loopback interface to restrict traffic destined to the router. The interface configuration should look similar to the following:

interfaces {
lo0 {
unit 0 {
family inet {
no-redirects;
filter {
input router-protect-filter;
}
address 10.10.2.1/32
}
}
}
}

Step 2: Verify the filter bound to the router’s loopback address restricts all control plane and management plane traffic. The filter configuration should look similar to the following:

firewall {
filter router-protect-filter {
/* police management and ICMP traffic */
policer mgmt-128k {
if-exceeding {
bandwidth-limit 128k;
burst-size-limit 2k;
}
then discard;
}
policer mgmt-64k {
if-exceeding {
bandwidth-limit 64k;
burst-size-limit 1k;
}
then discard;
}
policer icmp-64k {
if-exceeding {
bandwidth-limit 64k;
burst-size-limit 1k;
}
then discard;
}

/* drop framgmented ICMP messages */
term fragmented-icmp {
from {
protocol icmp;
is-fragment;
}
then {
syslog;
discard;
}
}
/* allow specific management plane traffic */
term ssh-access {
from {
source-address {
192.168.1.0/24;
}
protocol tcp;
destination-port ssh;
}
then {
policer mgmt-64k;
accept;
}
}
term snmp-access {
from {
source-address {
192.168.1.22/32;
192.168.1.24/32;
}
protocol udp;
destination-port snmp;
}
then {
policer mgmt-128k;
accept;
}
}
term tacacs-access {
from {
source-address {
192.168.1.101/32;
}
protocol tcp;
port tacacs-ds;
}
then {
policer mgmt-64k;
accept;
}
}
term ntp-access {
from {
source-address {
192.168.1.70/32;
192.168.1.77/32;
}
protocol udp;
port ntp;
}
then {
policer mgmt-64k;
accept;
}
}
term allow-ICMP {
from {
source-address {
192.168.1.0/24;
}
protocol icmp;
}
then {
policer icmp-64k;
accept;
}
}
/* allow specific control plane traffic */
term guard-bgp {
from {
source-address {
199.21.32.11/32;
199.21.32.12/32;
}
protocol tcp;
port bgp;
}
then {
syslog;
accept;
}
}
term guard-ospf {
from {
source-address {
199.21.32.11/32;
199.21.32.12/32;
}
protocol ospf;
}
then {
syslog;
accept;
}
}
…
…
…
term default-action {
then {
syslog;
discard;
}
}
}
}

Fix Text (F-19812r1_fix)
Implement control plane protection by classifying traffic types based on importance levels and configure filters to restrict and rate limit the traffic punted to the route processor as according to each class.